There seems to be some compilation failures:

 │ │ $SRC_DIR/ros-jazzy-usb-cam/src/work/include/usb_cam/formats/av_pixel_format_helper.hpp:747:32: error: 'AV_PIX_FMT_XVMC' was not declared in this scope; did
 │ │  you mean 'AV_PIX_FMT_XV30'?
 │ │   747 |   {stringify(AV_PIX_FMT_XVMC), AV_PIX_FMT_XVMC},                      ///< XVideo Motion

Not sure about those, but I see also that warnings are threated as errors, that is tipically not idea. If you find a patch that works, you can add it in patches/ros-jazzy-usb-cam.patch and will be applied as part of the generation process.

I guess we need ros-drivers/usb_cam#343, apparently the latest release is old and does not include that fix.

Yeah, #343 just removes the offending pixel format. Seems, like we have to duplicate this removal as a patch until new version of usb-cam is released

I will try to do that

Also, I wonder, does this failure mean that we do not pin ffmpeg version?

Ok, the pixel format error is gone, will take a look into warnings as errors

Also, I wonder, does this failure mean that we do not pin ffmpeg version?

There is no pinning in https://github.com/RoboStack/ros-jazzy/blob/main/conda_build_config.yaml, so apparently now. However, the only logical pinning for ffmpeg would be something compatible with the one specified in https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/be2ab14d09b61657d873852a567afdc340d468a4/recipe/conda_build_config.yaml#L306 (to avoid incompatibilities between conda-forge packages and robostack packages), and also there ffmpeg 7 (that is the latest major version) is pinned, so I guess in both cases you get the ffmpeg 7 .

Yay, this one should actually work!

Great, the build seems to work now, thanks! If you are interested in upstreaming to usb-cam the patch to allow disabling the Werror while keeping Werror ON by default (that is typically the behavior the upstream devs like) feel free to check ros-misc-utilities/ffmpeg_encoder_decoder#2 .

CI is happy, @elephantum do you think the PR is ready for merge?

Yes, I think so. There's no point to enable it for win/macos, as it is not supported in usb_cam

So we are good to go!

Yes, I think so. There's no point to enable it for win/macos, as it is not supported in usb_cam

So we are good to go!

Make sense, if that is v4l-based that is only available on Linux. Thanks for the contribution!